The present invention is directed to an adaptive de-spooling system for partial brute force collation.
Using a source device (e.g. any host or device used for creating or imaging a document including a computer or scanner) having an associated communication component (that may be implemented in hardware or software either directly in the source device or in a connected device or application—e.g. a printer driver or a downstream de-spooling component), a user may transmit an electronic document (e.g. any created document or image thereof to a printing device (e.g. any device used for printing including a traditional printer, copier, MFP, fax machine) to print multiple copies thereof. All of the copies of the document are collectively referred to as a print job. Ideally, the user wants the printed copies to be properly collated such that each copy is in the sequential page order according to the imposition requirement of the print job. For example, FIG. 1 shows a document having X pages (e.g. 100 pages) printed N times (100a-100N) and properly collated so that each printed copy is ordered such that page 1 is on top and page X is on the bottom of the stack of papers. (It should be noted that, depending on the printing device, the output may be “upside-down” such that output is face down and the stack must be “flipped” so that it is properly collated.) Depending on the capabilities of the printing device, properly collated output can be problematic.
RIP (Raster Image Processing) is the process by which document data is converted/prepared from one format (e.g. PDL) into a format suitable for printing (e.g. a bitmap) by the device's output engine. The product of the RIP (process) is referred to as a RIP or RIP data (formatted data or prepared version). The term “RIP” is meant to include any process by which a document is formatted into engine-ready data suitable for outputting by the device's outputting mechanism.
When a user initiates a print job with multiple copies of an electronic document, the printer driver must decide whether collation will be emulated on the source device (i.e. brute force collation) or performed on the printing device (e.g. RIP Once Print Many—ROPM).
A conventional printing device 110 such as that shown in FIG. 2 has limited or no memory and, therefore, cannot perform collation. This type of printing device requires that copy collation must be emulated on the source device. The Sharp AR-161 digital imager is an example of this type of printing device. FIG. 2 shows a source device 112 sending a document 114 to a printer driver 116. The printer driver 116 then performs brute force collation by sending N copies of the document data 118a-118N to a document preparation (e.g. RIP) component 120 of the printing device 110. The RIP component 120 must re-RIP each copy of the document data 118a-118N to create an associated RIP data 122a-122N to be output 124 by the printing device 110 in proper collated order (such as that shown in FIG. 1). The printing device 110 does not have sufficient storage capacity either to hold an entire copy of the document data or the entire RIP of the print job. Traditionally, a printer driver 116 for this type of printing device 110 emulates copy collation on the source device 112. For each of the N user specified copies, the printer driver 116 or a downstream de-spooling component (e.g. MS-WINDOWS® 2K EMF print processor) repetitively sends one copy of the document data to the printing device. Thus, in a four (4) copy print job, the source device 112 would send the printing device 110 four single copies of the document data. One problem with this system is that it generates excessive network traffic because N copies of the document must go over the network. Another problem with this system is that the printing device 110 must perform excessive computation by processing multiple copies.
FIG. 3 shows an improved printing device 130 that has ROPM capability and includes storage sufficient to hold both the print job data (job storage 132) and the entire RIP (prepared document or RIP storage 134) of the print job. The Sharp AR-M450 digital imager is an example of this type of printing device. As shown in FIG. 3, a source device 142 sends a document 144 to a printer driver 146. The printer driver 146 then sends one (1) copy of the document data 148 to the job storage 132 of the printing device 130. The printer driver 146 also sends a command for the number (N) of collated copies to output (e.g. @PJL SET COPIES=<N>). A RIP component 150 of the printing device 130 receives one (1) copy of the document data 152 and creates associated RIP data 154 that is held in RIP storage 134. From RIP storage 134 the RIP data may be transmitted multiple times (156a-156N) to be output 158 by the printing device 130 as output in proper collated order (such as that shown in FIG. 1). For example, an outputting mechanism 158 (e.g. outputting engine, marking engine) retrieves a copy of the entire RIP and prints the appropriate number of copies using ROPM. This system is limited by the size of the job storage 132 and the RIP storage 134 because the amount of memory required will always be less than that required for an arbitrary large document. Problems with collation occur when the printing device cannot hold the entire document data and the RIP in memory all at once.
FIG. 4 shows elements of printing device 170 that has ROPM capability and includes job storage 172 and RIP storage 174 implementing a “chunking technique” when the storage capacity of the printing device 170 is exceeded. The Sharp AR-507 digital imager is an example of a printing device 170 that performs the chunking technique. Using the chunking technique, the printing device 170 has enough storage for the entire job, but not for the entire RIP. Instead, using the RIP component 176 the printing device 170 processes a RIP in “sequential sheet out” order until reaching a storage threshold of the RIP storage 174. For example, if the storage threshold of the RIP storage 174 were ten (10) pages, the portion (or chunk) would be ten (10) pages 180a. The ten (10) page chunk would be sent to the RIP component 176 that would process the process chunk 181a. The RIP'd chunk 181a would be stored in the RIP storage 174 as RIP'd chunk 182b. At this point, the outputting mechanism 178 would output N copies of the RIP'd chunk 182a as an output chunk 184a (FIG. 5). The printing device 170 would then purge the RIP chunk 182a from the RIP storage 174. The next chunk 180b (e.g. pages 11-20) would then be RIP'd 181b, stored in the RIP storage 174 as 182b, and output N times 184b. This process would be repeated until the entire document is processed. The user then hand coalesces the chunks together such that the output is in the format shown in FIG. 1. FIG. 5 shows an exemplary print output from a printing device 170 using the chunking technique. Although this example shows the chunks divided into ten (10) pages and the document size being a hundred (100) pages, these numbers are meant to be exemplary. The disadvantage of the chunking technique is that the entire collation of the document is not automated. The user must perform some hand collation to complete the outputting process.